We added selector-max-specificity to Stylelint before the introduction of specificity-changing pseudo-classes like :is(), :where(), :not() and :has(). Having thought about it some more, I'm not sure the rule is useful these days.

Due to these pseudo-classes, it makes a poor proxy for controlling selector complexity and for disallowing ID selectors. For example, both these selectors have a specificity of 0,0,0:

:where(#id),
:where(a.complex[attr], #id) {}

And makes a poorer proxy for disallowing other types of selectors as it groups them:

• B = the number of class selectors, attributes selectors, and pseudo-classes
• C = the number of type selectors and pseudo-elements

It'd be good to hear if people have another use for this rule.

If you do keep it, the implementation should probably consider these specificity-changing pseudo-classes and nesting, which is Baseline 2023.

In Stylelint, we use @csstools/selector-specificity for calculating the specificity, which supports the specificity-changing pseudo-classes and elements. We also desugar nested selectors before passing them to the calculator. However, we don't yet desugar to :is() (as our current implementation predates the latest CSS nesting spec):

a, b { 
  & c {} 
}

/* should be desugared to */
:is(a, b) c {}

/* be we currently desugar to */
a c, b c {}

This can lead to different specificities, and our calculations may not match the browser.

Interesting. I think I'll need to dig into this a bit more.

Take a look at bramus/specificity. It appears to to cover all the key aspects of selector specificity calculation according to the latest CSS specifications. Since it’s built on top of CSSTree, it might be a good candidate for adoption instead of implementing a custom specificity calculation from scratch (see calculate.js).

@lahmatiy thanks! We're actually discussing over on #19 whether or not specificity even makes sense as a measure of selector complexity anymore. Would love to hear your thoughts.